Most computing devices utilize a firmware to control their low-level operation. The firmware is typically tied closely to the particular hardware components of the computing device. The firmware is generally stored in a non-volatile memory device, such as a read only memory (“ROM”), erasable programmable read only memory (“EPROM”), or a flash memory device. The firmware might be periodically updated in order to fix bugs or introduce new functionality.
In many types of computing devices, the firmware provides functionality for performing a power-on self-test (“POST”) of the computing device, for booting the computing device (which might also be referred to as performing an initial program load (“IPL”)), for providing interfaces to the low-level operation of the hardware of the computing device to an operating system executing on the computing device, and for performing other types of functions.
Many desktop, laptop, and server computers utilize a firmware known as a legacy Basic Input and Output System (“BIOS”) firmware. Legacy BIOS includes low-level instruction code that is used as an intermediary between the hardware components of the computing system and the operating system and other high-level software executing on the computing system. For example, legacy BIOS might provide a set of software routines that allow high-level software to interact with the hardware components of the computing device using standard calls.
Other desktop, laptop, and server computers might utilize an Extensible Firmware Interface (“EFI”)-based firmware, such as a firmware that is compatible with the Unified Extensible Firmware Interface (“UEFI”) Specification from INTEL CORPORATION. Computing devices might also utilize the OPEN FIRMWARE specification from SUN MICROSYSTEMS or another type of open or proprietary firmware to control various aspects of their operation.
Legacy BIOS firmware and EFI-based firmware typically provide a simple boot flag register or variable (referred to herein as a “simple boot flag data structure”) that can be used by an operating system to communicate boot options to the system firmware and add-in card option ROMs. This allows firmware and operating systems to automatically optimize their behavior and boot performance based on the installed operating system and the results of previous boots. For example, this mechanism might be utilized to determine when to run diagnostic tests during boot and/or to determine whether to configure hardware resources for devices. A Simple Boot Flag Specification has been published by MICROSOFT CORPORATION that describes aspects of the use and operation of the simple boot flag data structure described above.
Creating and testing program code that implements the Simple Boot Flag Specification in a firmware can be a complex and time consuming process. For example, previous mechanisms for testing firmware code that performs simple boot flag processing might take an hour or more to complete. The lengthy time required to test this program code can be frustrating for the engineers responsible for creating and testing the simple boot flag processing program code.
It is with respect to these and other considerations that the disclosure made herein is presented.